The C and C++ language standards are among those that support the xe2x80x9cvolatilexe2x80x9d type-qualifier for compiler operation. For example, as stated in the 1990 American National Standard for Information Systems Programming Language C (hereinafter referred to as the xe2x80x9cANSI Standardxe2x80x9d): xe2x80x9cAn object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects.xe2x80x9d
A programmer may use the volatile type-qualifier for a variety of reasons, such as to enable accesses to shared memory, or to memory-mapped I/O locations (so as, for example, to communicate with external devices). Alternatively, the volatile type-qualifier may be used to enable access to locations that may be asynchronously accessed by an interrupt handler.
Accordingly, compilers, and more specifically compiler optimization phases, tend to be very conservative in the treatment of accesses to objects with volatile-qualified type in order to adhere to the standard and to accommodate the spectrum of applications of the volatile keyword. This conservative approach often results in a loss of compiler optimization opportunities and hence adversely affects run-time performance.
Compilers generally treat an access to a volatile type-qualified object in a universally inflexible manner. Specifically, for example,
a volatile load or store is never deleted or transformed into a register reference;
a volatile load or store is emitted with an xe2x80x9corderedxe2x80x9d completer to ensure sequential run-time hardware execution on weakly ordered systems;
no memory reference instructions are scheduled across a volatile load or store; and
a volatile load or store is never moved to a location where it could be executed xe2x80x9cspeculatively.xe2x80x9d
It is not always necessary to take such a universally inflexible approach. Sometimes selected optimizations could be allowed without endangering compilation integrity. These selected optimizations could help recover otherwise lost optimization opportunities and thereby enhance run-time performance.
Operating systems, in particular, have a need to declare a wide variety of data accesses as volatile in order to prevent incorrect compiler optimization of kernel code. However, this adversely affects performance, sometimes more than necessary. For instance, on weakly ordered systems, the volatile type-qualifier may be specified solely to ensure that the compiler emits a memory reference instruction to the volatile type-qualified object using a xe2x80x9cstrongly orderedxe2x80x9d memory reference opcode or completer. In some programming applications, however, it may be perfectly acceptable for the compiler to perform certain selected optimizations, such as local register promotion on accesses using a xe2x80x9cstrongly orderedxe2x80x9d completer, even though such transformations might not be safe to perform on all volatile references in general.
There is therefore a need for a regime of keywords that modify the general volatile type-qualifier, and whose selected use will permit (or not permit) certain optimization operations in compiling code containing references to volatile data.
These and other objects and features are achieved by one embodiment of the invention which comprises a system that enables a programmer to relax optimization constraints and requirements that are otherwise associated with volatile memory reference by default. Specifically, these relaxation xe2x80x9chintsxe2x80x9d can be expressed either as additional modifying type-qualifiers or as pragmas to loosen the restrictions associated with the volatile type-qualifier. By way of example (and without limitation), four (4) such relaxation hints are illustrated below that bring technical advantage to a corresponding volatile access described therewith:
a. relaxing asynchronicity of the access: a volatile access that is guaranteed to be synchronous allows local register promotion and eliminates redundant definition of volatile loads and stores.
b. relaxing strong ordering requirements: if the underlying hardware does not need to observe strong ordering constraints when executing a volatile memory access, the corresponding load or store need not be marked with the ordered completer, which in turn allows faster execution of such references at run-time.
c. relaxing constraints on compiler scheduling freedom: a volatile access that does not need to be executed sequentially relative to other non-volatile references can be scheduled better by the compiler.
d. relaxing constraints on control speculation freedom: a volatile access that does not refer to a memory-mapped I/O location can be re-ordered to execute speculatively ahead of controlling branches, again leading to potentially higher run-time performance.
Accordingly, one technical advantage of the invention is that a programmer is allowed to facilitate increased optimization of accesses to volatile type-qualified objects in contexts where it is safe and advantageous to do so.
Another technical advantage of the invention is that the system allows a programmer to selectively increase the aggressiveness of the compiler for certain code which would otherwise be compiled in a conservative (non-aggressive) manner.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and the specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.